Someone is attempting to deploy a commit to the React Component Team on Vercel.

A member of the Team first needs to authorize it.

Walkthrough

在 src/Select.tsx 的 tags 模式中统一跳过禁用 option 的值：临时 tag 生成、提交处理和分词合并都会过滤 disabled 值。tests/Tags.test.tsx 新增了 blur、Enter 和分词场景的回归用例。

Changes

Tags 模式禁用值过滤

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• zombieJ
• afc163

Poem

🐰 我跳进 tags 的小花园，
禁用的果子不入篮；
blur、Enter、分词忙一圈，
该跳过的值，悄悄走远。

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.44%. Comparing base (1169cb8) to head (44e19fa).

@@           Coverage Diff           @@
##           master    #1227   +/-   ##
=======================================
  Coverage   99.44%   99.44%           
=======================================
  Files          31       31           
  Lines        1265     1272    +7     
  Branches      441      444    +3     
=======================================
+ Hits         1258     1265    +7     
  Misses          7        7           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

这个方向可以解决 blur 触发的问题，不过我觉得可以再收敛一下实现边界：这里本质上是 tags 模式在“创建新 tag”时需要避免复用已有 disabled option 的 value，而不只是 submit 分支需要拦截。

现在只在 onInternalSearch 的 source === "submit" 分支里判断 valueOptions.get(formatted)?.disabled，可以覆盖失焦/关闭状态回车提交。但 filledSearchOptions 里仍可能基于同一个 search value 生成临时 tag option，尤其是自定义 filterOption 导致原 disabled option 不出现在过滤结果里时，后续从 dropdown 选择这个临时项仍可能绕过 disabled option 的语义。

建议抽一个小判断，例如：

const isDisabledOptionValue = React.useCallback(
  (val: RawValueType) => !!valueOptions.get(val)?.disabled,
  [valueOptions],
);

然后同时用于两个地方：

1. filledSearchOptions 中，如果 mergedSearchValue 命中 disabled option，就不要创建临时 tag option。
2. source === "submit" 分支中，如果 formatted 命中 disabled option，就只清空输入并 return，不触发 triggerChange / triggerSelect。

这样规则会更靠近“tag 创建边界”，也能避免同一个 disabled value 通过不同入口被创建出来。测试上除了现在的 blur case，最好再补一个 filterOption={() => false} / dropdown open 的场景，确认不会生成可选的临时 tag。

又看了一下更新后的版本，整体方向已经比最初更完整了：filledSearchOptions、submit 和 token split 都覆盖到了。

还有两个小点建议再收一下：

1. filledSearchOptions 的 useMemo 里用到了 isDisabledOptionValue(mergedSearchValue)，依赖数组里需要补上 isDisabledOptionValue，否则 valueOptions 变化时这里可能拿到旧判断。

2. 数字 value 的处理现在是：

valueOptions.get(String(val))?.disabled || valueOptions.get(Number(val))?.disabled

这个会有点宽。比如同时存在 { value: "1", disabled: false } 和 { value: 1, disabled: true } 时，输入 "1" 会先命中 enabled 的字符串 option，但因为后半段又命中了 disabled 的数字 option，最终仍会被当成 disabled。Number(val) 还会把 "01"、"1e2" 这类输入转成别的 number value。

更稳一点可以先尊重 exact raw value，再只在没有 exact match 时做字符串化匹配，例如：

const isDisabledOptionValue = React.useCallback(
  (val: RawValueType) => {
    const exactOption = valueOptions.get(val);
    if (exactOption) {
      return !!exactOption.disabled;
    }

    return Array.from(valueOptions).some(
      ([optionValue, option]) => String(optionValue) === String(val) && option.disabled,
    );
  },
  [valueOptions],
);

这样可以覆盖输入 "123" 对应 disabled numeric option 的场景，同时不会让数字转换误伤已有的字符串 value。

我再想了一下，这里可以更简单一点，不一定要为 numeric value 做额外兼容。tags 模式里用户输入本身是字符串，如果要把 "123" 视为命中 { value: 123 }，这里会引入 string/number value 冲突的语义问题，反而让修复变复杂。

建议先只修 exact value 命中的 disabled option：

// filledSearchOptions
if (valueOptions.get(mergedSearchValue)?.disabled) {
  return filteredOptions;
}

// submit
if (valueOptions.get(formatted)?.disabled) {
  setSearchValue("");
  return;
}

如果保留 tokenSeparators 的处理，也可以同样用 exact match：

patchValues = patchValues.filter((val) => !valueOptions.get(val)?.disabled);

这样可以去掉 isDisabledOptionValue 这个 helper、去掉 String/Number 转换，也不会有额外 hook deps 问题。测试上保留 blur 和 filterOption={() => false} 这两个核心 case 就够了；numeric value 可以先不覆盖，除非我们明确决定 tags 输入字符串需要匹配数字 option value。